Identity management docs

[heiko.braun]

I am looking for any docs on the identity management component. The user guide chapter is too much high-level. I am more interested in topics on integration and extensibility.

- I.e. how does it work within the web console?
- What mechanism could the web service facade leverage?

Any hints welcome.

Btw, this really done?
http://jira.jboss.com/jira/browse/JBPM-429

[kukeltje]

Heiko,

There is not much documentation about this. For the PVM a new identity 'module' is developed. I hope this will integrate better with e.g. the portal usermanagement module or the parts of seam. To be honest, I'd hope that JBoss will make a separate 'shared/common' thing out of this and e.g. combine it with the SSO.

Ok, now some real answers

The webconsole takes the credentials from the webcontainer. So cert, basic or form based authentication can be used. There is some work going on within JBoss (afaik) to develop a new(er) (again) console based on seam.

The starterkit has a login config for AS that verifies credentials in the jBPM database, but that could be any system. Currently users have to be in the jbpm database as well in combination with having certain roles in there. Although this identity module can be 'replaced', it is not very easy to do and there are some weird dependencies. I have been trying to replace the current identity module with one based on ldap, but failed because of these dependencies and the identity module not really being a 'service' like persistency, subprocessresolver etc...

The WS facacde could (should?) leverage the same mechanism/

Regarding JBPM-429, not sure if it is done, I'd have to check the source to see.

[heiko.braun]

Thanks.
I think WS username token profile ( http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf) would be the best approach to add security to the WS facade. The current implementation delegates to the jboss security framework. It integrates nicely with the other AS components. However I somehow need bridge the gap towards the JBPM identity management. Who's maintaining that code?

[tom.baeyens]

"Who's maintaining that code?"

that would be me, i guess :-)

the jbpm identity component is pretty straight forward. there are 3 main classes User, Group and Membership. These are mapped to the database to 3 tables.

in module jbpm.3/jboss/configuration, there are (per AS version) a number of configuration files. in the login-config.xml there is the declaration of the jbpm security domain. it is a database login module that checks the user name and password in the database. it also extracts the roles from the DB tables as follows:

<application-policy name = "jbpm">
 <authentication>
 <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule"
 flag="required">
 <module-option name="dsJndiName">java:/JbpmDS</module-option>
 <module-option name="principalsQuery">
 SELECT PASSWORD_ FROM JBPM_ID_USER WHERE NAME_=?
 </module-option>
 <module-option name="rolesQuery">
 SELECT g.NAME_ ,'Roles'
 FROM JBPM_ID_USER u,
 JBPM_ID_MEMBERSHIP m,
 JBPM_ID_GROUP g
 WHERE g.TYPE_='security-role'
 AND m.GROUP_ = g.ID_
 AND m.USER_ = u.ID_
 AND u.NAME_=?
 </module-option>
 </login-module>
 </authentication>
 </application-policy>

[tom.baeyens]

i don't know yet what the best layer is to plug in the ws security. meaning the SQL/JDBC level or the Java/hibernate level. i would say: whatever is most convenient.

i assume that whatever security we use, it will be optional right. cause i think that not all clients will know on behalf of which user they are running the code.

[heiko.braun]

I don't know yet what the best layer is to plug in the ws security.

Well, for the protocol it's the username token profile. The current JBossWS implementation delegates to JAAS as well. So we may just delegate to the jbpm security domain for WS authentication.

From what I understand, the WS facade doesn't need to bother about further authorization, does it?

That would be:

WS -> WSSE -> JAAS -> JBPM

(WSSE is webservice security)

[tom.baeyens]

i don't fullly get it from that short description. but it doesn't really matter. you can explain me the details in orlando.

and in the meantime, just completing the impl should validate if it actually works. that is always a good sign :-)

[heiko.braun]

WS -> WSSE -> JAAS -> JBPM

I thought pictures tell more than words ;)

lol

[tom.baeyens]

ROFL !

i was referring to the way the technologies are used and combined. especially the WSSE --> JAAS link.

that means creating a LoginContext and doing a login and logout. and then performing the operation with one of the doAs methods on the Subject, right ?

or does it imply authorization checks as well ?

[heiko.braun]

or does it imply authorization checks as well ?

No, that's JBPM responsibility.

[tom.baeyens]

ok. makes sense.

[heiko.braun]

I mean the WS facade doesn't deal with it. I would expect the JDPL core to deal with authorization when the command facade is used. Does it callback JAAS?

[tom.baeyens]

no. there is no way to specify authorization in the process language. and hence there are no authrorization checks.

but there is authentication. things like logs require authentication. to keep track of who did what. the JbpmContext has a property actorId. JbpmContext delegates to an AuthenticationService to get the actorId.

The simplest way to get the actorId in the JbpmContext is to use jbpmContext.setActorId(String).

An idea could be to implement a JaasAuthenticationService. That one could look up the subject from the current thread, take the main principal and get its name. That principal name could be used as the actorId in the JbpmContext.

This will work for WS requests. But I don't know if this will work for other requests like ejb invocations and web requests. I'm not even sure if authentication is required all the time. If you have time, it could be an option to explore.